From the days when an embedded system was built around a PDP-8 and a rack full of interface electronics, the species has had some distinctive traits. The microprocessor changed everything, of course, condensing a whole rack of stuff onto a backplane-and, later, onto a board. Still, much remained the same.
In recent years we have seen further elaboration on the theme: DSP chips, multiple processors, the advent of ASICs to implement some of the stuff.
Today, we are seeing another step in this evolution. With the possibility of getting all the active components of an embedded system onto a single system-on-chip, we have made possible the embedded SoC. In this environment, the possibilities for multiprocessing, highly complex peripherals and specialty memories increase, and many of those old invariants will take on quite new meanings.
One case in point is the importance of architectural planning. Understanding the state transformations and data flow of the application, and mapping these onto appropriate hardware blocks, is, if anything, more critical to an embedded SoC than it was to a board-level design.
You won't get the opportunity to add another processor core or double the cache size during system integration if all the hardware is on one die, and you just wrote a half-million-dollar check for the masks.
Similarly, the difficulty of verification-a theme quite familiar even to the PDP-8 programmers of the 1960s-is exacerbated by the SoC design flow. It's hard to get any kind of development platform to the software folks early enough. It's hard to verify the hardware in the absence of reasonably good software. And even with chips in hand, it's hard to get enough visibility of the major blocks to do adequate hardware/software integration testing.
In this issue we crack open the lids on some of these boxes to see what evils might be inside. Our cover story explores a prime example: How do you implement a wide enough range of memory interfaces on an SoC to meet the needs of all the systems developers who might want to use the chip? It's a problem that would never come up if the memory controller were on a plug-in daughtercard.
Another couple of examples: At the board level, laying out a moderate-speed board-level computer pcb is interesting, but a well-understood task. Floor planning a large FPGA with an on-chip CPU core is far less understood, and in fact presents some interesting challenges. And embedding a nonvolatile memory on an SoC requires many more considerations than would be necessary if you were just buying a flash module to plug into your board-level computer.
Finally, we examine the ultimate reality check for the embedded-system SoC.
Is it feasible to dream this dream in the first place? We follow the experiences of one management team as it decides that an SoC is the right way to go, assemble a design team capable of conducting a COT design and take the part to completion.
It's the same old embedded-computing story. But it's a whole new world, and many of the pivotal questions are still awaiting good answers.
---
http://www.isdmag.com
Copyright © 2002 CMP Media LLC
3/1/02, Issue # 14153, page 4.
